背景和动机
参考年底攻坚项目背景：https://docs.popo.netease.com/lingxi/f946eeb5180d4f5b9db92157e252ce42#edit
- 赋值多字段代码量过大，操作过于繁琐
- Transform 函数的大多数交互是返回一个新构造的实例
示例 1：批量赋值
已知的内置库和一些数据结构：
老的代码语义
详细设计
最基本的二元赋值根据类型分析
| typeof 左边 \ typeof 右边 | 基础类型 | 复合类型 | List { length } | Map |
|---|---|---|---|---|
| 基础类型 | 本身 | 本身或某级子字段 | 本身或 length | 本身 |
| 复合类型 | 本身 | 本身或某级子字段 | 本身或 length | 本身 |
| List { length } | 不允许 | 不允许 | 不允许 | 不允许 |
| Map { values, keys } | 不允许 | 不允许 | 不允许 | 不允许 |
批量赋值方案一：类似 Object.assign 的设计
优点
- 路径短，省事
- 实现成本低
缺点
- 左右只允许复合类型
- 自定义程度不高，其他功能仍然需要普通赋值解决
- 与 Transform(map) 函数结合不起来
批量赋值方案二：多变量批量赋值（采用此方案）
批量赋值和 Transform(map) 很容易让人想到连线映射的交互。
语义原理：Parallel assignment，TypeScript/JavaScript 中的数组析构赋值。
Java 示例：
优点
- 可以代替原来的简单赋值
- 与 Transform(map) 函数容易结合
缺点
- 复杂起来线很多
- 要不要支持表达式塞入？可能会很重量级
- 顺序要理清
- 其它问题见交互稿
批量赋值方案三：坑位批量赋值
左边只能选择复合类型的变量，右边随意。
优点
- 相比方案一，右侧灵活性更高
- 交互和以前的比较接近，适配性高，与之后 Transform(map) 的交互一致性高
- 没有明显的顺序问题
- 实现成本较低
缺点
- 选变量可能没连线方便和直观
- 左侧只允许复合类型
Transform 方案一：坑位 New 函数
假定最近的版本中，Transform 的 lambda 只支持放一个表达式。
| lambda 返回类型为 | 基础类型 | 复合类型 | List { length } | Map |
|---|---|---|---|---|
| 交互形式 | 使用一个“选择变量框” | 构造器 | 可能也是想要构造器 | 构造器？ |
示例 2：使用 Transform 的表达
这里貌似主要应该扩充 New 内置函数的能力，原来的 New 函数的交互最接近“坑位批量赋值”。
优缺点与“批量赋值方案三：坑位批量赋值”一样。
Transform 方案二：连线 New 函数（采用此方案）
与上一种方案语义一样，只是交互不同。
优缺点与“批量赋值方案二：多变量批量赋值”一样。
结论
- 连线和坑位
- 选择连线
- 赋值和批量赋值要不要分开？
- 右侧工具栏只有允许有一个赋值组件
- 遗留交互问题：普通赋值和批量赋值的切换问题（交互已解决）
- 遗留交互问题：泳道连续快捷添加（交互已解决）
- 左右表达式
- 右侧允许多个任意表达式
- 左侧只允许一个任意表达式
- 自动连接
- 字段名或变量名和类型和左边都匹配才能自动连接
- 没有连线的字段
- 遗留交互问题：没有连线类似 unused expression，可以加个未使用的效果（交互已解决）
- 左侧字段来源唯一
- 不允许多条线同时连入左侧一个点
- 不允许父子同时产生连线
- 通过互斥解决掉了顺序问题
- 折叠字段的交互
- 遗留交互问题：折叠起来线的交互交互（交互已解决）
- 递归引用和空指针问题
- 递归引用只允许展开一级（其他用户自己想办法吧）
- 空指针运行时报出
- 相同类型的 item 可以通过拖拽取代掉
未解决的问题
- 后续考虑：字段要计算、流式数据处理等
- 只读属性需要在语法树上添加一种区分
- 批量赋值的语法树等确定方案后再设计
- 批量赋值的全键盘操作